The present invention relates generally to graphical user interfaces for computer systems. More particularly, the present invention relates to a method and apparatus for providing menu tools generally associated with application user interfaces from an operating system.
The evolution of the computer industry is unparalleled in its rate of growth and complexity. Personal computers, for example, which began as little more than feeble calculators with limited memory, tape-driven input and monochrome displays are now able to tackle almost any data processing task with highly integrated high speed processors, gigabyte storage, high resolution video displays, and the now ubiquitous “mouse” input technology, which revolutionized the industry with the concept of “point-and-click”. While this meteoric increase in processing speed and power, storage capacity, and input and output technology was almost sufficient to satisfy the demand of application designers and end users alike, the corresponding increase in complexity created an ease-of-use problem which the industry was somewhat slower in solving. Thus, designers were faced with a new challenge: to harness this computing power in a form usable by even those with relatively little computer training to smooth the transition of other industries into a computer-based information paradigm.
As a result, in the early to mid-1980's many new I/O philosophies, such as “user friendly”, “WYSIWYG” and “menu driven” came to the forefront of the industry. These concepts are particularly applicable to microcomputers, also known as personal computers, which are intended to appeal to a broad audience of computer users, including those who previously feared and mistrusted computers. An important aspect of computers which employ these concepts was, and continues to be, the interface which allows the user to input commands and data and receive results, which is commonly referred to as a graphical user interface (GUI).
The success of the GUI type human interface is evident from the sheer number of companies which have either emulated the virtual desktop environment or developed applications designed to operate in one. Even successful concepts, however, must continually be improved in order to keep pace with the rapid growth in this industry. For example, with the advent of multimedia, driven by technical advances in networking such as the Internet, and high capacity/fast access data storage devices such as CD-ROM devices, capable of providing streaming audio and video, application designers and users alike, demand additional functionality and greater ease of use from the desktop environment.
To appreciate the challenges associated with continuing GUI design, consider an early and continuing example of a GUI which has evolved over time: the Finder™ user interface and information management system (simply “Finder™ user interface” hereafter) associated with the Apple Macintosh™ computer. The Finder™ user interface is based on display principles using “windows” and “icons” to help manage computer information, launch applications, perform system management functions, and the like. The main or root window is called the “desktop” area, or more generally the primary display region. The desktop, or primary display region, is always open (displayed on the screen with its contents accessible or at least partially accessible), and takes up substantially the full display screen area when other windows are not open. The desktop is usually visible in the background when “icons” are displayed thereupon and other windows are open to other than their full size.
Icons are graphical objects which represent and serve to identify information, system resources, applications, and the like, and may exist inside any particular window, including the desktop itself. An icon may be associated with a particular collection of computer information, typically representing a “file” which may be a collection of data, a particular device or device handle, an application, program, and the like. An icon also may represent a window corresponding to, for example, an application in an active but “minimized” state. As described, icons are graphic images which may be displayed on the computer screen and usually correspond in appearance to the type of information, system resource, or application which the icon provides access to when the icon is visible. The use of icons and windows is well known in the art.
A “file” generally refers to a collection of information which the user wishes to use, create or modify; each particular file has an associated unique name for identification by both the system and the user. Therefore, any given file may be located within the information management system by knowing a file name, an iconographic representation associated with the name, or a window name associated, for example, with a group of files which are stored together. All information (files) grouped within a particular window may be identified with that particular window's own identification location within the computer information management system. Therefore, any particular file information can be retrieved knowing its particular identification name and its window name. Accordingly, a Finder™ user interface screen display, for example, may be broken down into multiple windows and graphic icons.
Another important element of conventional user interfaces is a screen cursor. The cursor allows direct user control over the user interface and generally represents the point on the desktop which is presently “active”, e.g. where input may be received, or output may be seen or taken. The Finder™ user interface may be complemented with a “mouse” and a corresponding “pointer” which makes up the cursor control device and provides the “point-and-click” user interface. The pointer may be used to change where on the desktop the active cursor is at a given time. A mouse is an electromechanical device that translates two-dimensional mouse movement controlled by a user into a two-dimensional screen position movement represented by, for example, a pointer or arrowhead. The user may contact and direct the mouse while observing the position of the pointer on the screen thus bringing the user and the computer closer together via the interaction between the user, the mouse, the pointer and the display. When the mouse is moved signals are generated and input to the computer on an input port and the pointer moves correspondingly to a point on the display. Visual feedback may be used to control the exact location of the pointer by movement of the mouse. In addition, the computer may store the location of the pointer which corresponds to an exact location on the display. It should be noted that the computer may also store the location of each icon or other interactive object such that when the pointer and an icon location coincide, specific actions may be taken by the user to “activate” the icon as described in greater detail herein below.
The mouse may also be provided with one or more push buttons which may be used to effectuate control over the pointer by selecting or deselecting specific icons or other interactive tools. The mouse may be considered to be “activated” when the mouse button is depressed and the pointer remains active until the button is released. Pointer activation may also be initiated by sequences of mouse button presses, such as a “double click” interaction which involves rapidly pressing the mouse button press twice in sequence. By placing the pointer in a new location on the desktop and “clicking” or “double clicking”, the location of the active cursor, for example, may be changed to a new window, or, for example, an application may be launched by “double clicking” on the application's icon. However, as the desktop-becomes increasingly crowded with icons, open windows and other selection options problems may arise.
Not surprisingly, GUI problems have received a significant amount of attention in recent years. Several GUI products have been developed which provide different solutions to the manner in which frequently used and currently active desktop objects are handled by the GUI. For example, consider the conventional GUI depicted in FIGS. 1(a) and 1(b). Therein, a “Desk Drawer” concept is implemented to provide selectively hideable access to frequently used desktop objects. FIG. 1(a) depicts the screen 75 having a desktop area 20 with the Desk Drawer closed, wherein only the handle 10 of the Desk Drawer is visible. An open window 60 containing several document icons 55-58 which are, therefore, accessible for operations by the user via cursor 50. The window 60 also includes a window title field 65 and window select region 74.
When activated, e.g., by placing cursor 50 over handle 10, the Desk Drawer “opens” to reveal its contents. In this case, icons 41, 42, 51 and 59 become visible. Now that these icons are visible, they too are available for manipulation by the user via cursor 50. Thus, the Desk Drawer concept provides a mechanism for placing frequently used icons in an out of the way, yet easily accessible location. The interested reader is directed to U.S. Pat. No. 5,657,049, entitled “Desk Drawer User Interface” for a more in depth discussion of this technique, the disclosure of which is incorporated here by reference.
Another conventional GUI, i.e., that provided with the WINDOWS 95 Operating System, tackles the problem of desktop clutter by the provision of a taskbar to organize concurrently running applications as shown in FIG. 2. Therein, the desktop window 200 includes a plurality of icons 210 as well as the taskbar 220. The icons 210 provide “shortcuts” to applications or documents which can be invoked, e.g., by “double-clicking” on the desired icon. The taskbar 220 identifies windows which are active including both those which are maximized and “minimized”, i.e., are not currently displayed on the desktop 200. Each such active application is represented on the taskbar 220 by a corresponding button, which typically has an iconic representation of the application as well as some descriptive text. As new applications are launched, representative buttons will be added to the taskbar 220, from left to right. Each existing button will be scaled in length to permit the taskbar to accommodate new buttons. To “maximize” an application residing on the taskbar 220, the user can single click on the representative button. Another feature sometimes seen in this type of conventional GUI are application bars, e.g., appbar 230. Appbar 230 typically includes a number of smaller buttons (relative to the length of buttons on the taskbar when only a few applications are resident there), which buttons can be depressed to launch a currently inactive application.
This conventional GUI, however, suffers from the drawbacks of having a rather rigidly structured layout (e.g., the user cannot select or organize the order of the buttons on the taskbar 220) and from difficulties in handling the representation of a large number of applications. As more buttons are added to the taskbar 220, each individual button becomes smaller. When, for example, between 20-30 applications have been launched and minimized, the taskbar 220 begins to add new buttons as a second layer rather than continuing the line of buttons illustrated in FIG. 2. To reach the second layer, the user must toggle the taskbar 220, i.e., not all of the buttons are visible simultaneously on the GUI. As the power of computers and number of interesting applications, documents and other objects increases, it is anticipated that users will wish to have ready access to a growing number of objects and, therefore, will find the approach depicted in FIG. 2 to be cumbersome.
Another conventional GUI which attempts to solve this particular problem can be found in the NeXT™ Operating System. As illustrated in FIG. 3, and further described in U.S. Pat. No. 5,146,556, entitled “System and Method for Managing Graphic Images” (the disclosure of which is also expressly incorporated here by reference), this GUI provides an application “dock” 300 including a column of icons on the right side of the screen 310. The dock 300 is described as providing a visible mechanism for starting applications.
Although somewhat more flexible in terms of allowing the user to organize its content than the taskbar/appbar of FIG. 2, the application dock 300 still suffers from its limitations in terms of the number of applications which can be docked at any one time. For example, since the icons in the dock may generally be of a fixed size, there may be a limit to the number of icons which can be included in the dock at any one time. It will be appreciated however, that such limitations may be overcome and more icons may be displayed as constraints change or diminish.
Similar problems may arise upon launching applications, a document editor for example, where the use of the GUI is transformed into a more intensive series of menu selections, text insertion, graphical object insertion, and the like. Use of the GUI may become more repetitive with some menu items being used relatively infrequently but nevertheless being displayed and being present as a selection option in the menu even though rarely used. Accordingly, during certain operations within an application, menu use may become tiresome with infrequently used menu items being in the way of the task at hand. Like the appbar, taskbar, and application dock, as described herein above, application toolbars are a familiar feature in many applications and other Graphical User Interfaces (GUI).
Toolbars offer easier and more direct access to key commands of an application by presenting these commands as buttons either as part of the application's primary task window as is illustrated in FIG. 4A or in a floating window as illustrated in FIG. 4B. Toolbars are typically programmed by an application developer as part of an application program since the function associated with the toolbar selection is often closely tied to one or more functions performed by the application. Problems arise, however, in that if a configuration change is needed in the application requiring, for example, that new functions must be added to the application toolbar, a separate and complex human interface dedicated to the task of adding the new function is required. Often times, rebuilding of the application (e.g. compiling, linking, and the like) is needed to change the configuration of the toolbar. Moreover, as other, similar applications are used, a separate toolbar must be configured for each application and deliberately saved to preserve the new toolbar settings for the particular application.
Thus, it can be seen that while the above mentioned GUIs address certain issues and problems, there remains a need to provide the user with a larger degree of flexibility in terms of both the layout of the application toolbar which manages frequently used application menu objects, as well as permitting a larger number of such objects to be managed and simultaneously displayed and used across several applications which contain similar menu objects. It would therefore be appreciated in the art for a method and apparatus for increasing the capability and flexibility of application toolbars.